-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
O3-2448 - Visit queue number customization #44
Conversation
@@ -74,42 +64,6 @@ public Long getQueueEntriesCountByConceptStatus(@NotNull String conceptStatus, C | |||
return (Long) criteria.uniqueResult(); | |||
} | |||
|
|||
@Override |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic here (combined with the logic in the service below) has essentially been moved to the VisitAttributeQueueNumberProcessor. Implementations that want to retain this behavior can enable that processor by setting it on the service from a downstream module. That said, if we don't feel this is something we need/want to keep in the main codebase, I'd be supportive of moving the entire VisitAttributeQueueNumberProcessor over to a Palladium module, and not having to support that within the module.
Note, the code relocated to the processor is not exactly the same. It does not hit the DAO, but rather just iterates over the entries in the queue to achieve the same result. This may need to be optimized for speed, but didn't want to do that pre-emptively if this ultimately gets moved out of the module.
It was never really clear to me what purpose the location had here, given that queue has a location on it. If there needs to be different location than that of the queue or the visit, this will need to be looked at. That said, there are some potential issues in this method as documented in O3-2448, so it likely needs a review overally
.createQueueEntry(visitQueueEntry.getQueueEntry()); | ||
visitQueueEntry.setQueueEntry(newlyCreatedQueueEntry); | ||
return this.dao.createOrUpdate(visitQueueEntry); | ||
public synchronized VisitQueueEntry createVisitQueueEntry(@NotNull VisitQueueEntry visitQueueEntry) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made this method synchronized, as there tend to be situations where the queue number to generate is based on the queue entries and/or existing queue numbers assigned that exist in the database, and may need to protect against several threads generating the same queue number at the same time in different threads. See some of the comments in O3-2448
visitQueueEntry = dao.createOrUpdate(visitQueueEntry); | ||
|
||
if (visitQueueEntryProcessor != null) { | ||
visitQueueEntryProcessor.beforeSaveVisitQueueEntry(visitQueueEntry); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the main area that addresses the issue and allows customization. If a visitQueueEntryProcessor is set on the service, then it will be called to generate and/or populate any properties of the visitQueueEntry prior to final saving and completion of the transaction. An initial call to save happens before this is invoked in case this want to use generated data from the first save (for example, the primary key id).
*/ | ||
@Slf4j | ||
@Component | ||
public class BasicPatientQueueNumberGenerator implements VisitQueueEntryProcessor { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I originally had a different implementation here that was a bit more complex, but in the end I decided to make this as basic as possible. This may mean this is never appropriate for use in any real implementation, but it does serve to provide a default implementation and an example of how one would create a custom generator.
|
||
/** | ||
* Implementation of a VisitQueueEntryProcessor which aims to retain legacy functionality using | ||
* visit attributes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is where I've attempted to recreate the logic from the original DAO methods that were removed.
String queueNumber = prefix + "-" + paddedString; | ||
|
||
// Associate this queue number directly | ||
queueEntry.setPatientQueueNumber(queueNumber); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was not in the original implementation, but I see no harm in it, and I think for a generic front-end implementation we'll need this - the data for queue number in a known, fixed attribute of the queue entry - even if is also duplicated elsewhere (eg. a custom visit attribute).
VisitAttribute visitAttribute = new VisitAttribute(); | ||
visitAttribute.setAttributeType(visitAttributeType); | ||
visitAttribute.setValueReferenceInternal(queueNumber); | ||
visitQueueEntry.getVisit().addAttribute(visitAttribute); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's possible / likely that with the new column, this is not longer behavior that is desired. But I'll leave that to others to discuss and decide.
@@ -244,16 +241,4 @@ public void shouldZeroCountQueueEntriesByBadStatus() { | |||
assertThat(queueEntriesCountByStatusCount, notNullValue()); | |||
assertThat(queueEntriesCountByStatusCount, is(0L)); | |||
} | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test was moved / reimplemented below.
@@ -13,8 +13,8 @@ | |||
<concept concept_id="1000" retired="false" is_set="true" creator="1" date_created="2022-02-02 14:31:00.0" uuid="897eba27-2b38-43e8-91a9-4dfe3956a35t"/> | |||
<concept concept_id="1001" retired="false" is_set="false" creator="1" date_created="2022-02-02 14:40:00.0" uuid="90b910bd-298c-4ecf-a632-661ae2f446op"/> | |||
<concept concept_id="1002" retired="false" is_set="false" creator="1" date_created="2022-02-02 14:40:00.0" uuid="91b910bd-298c-4ecf-a632-661ae2f909ut"/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The below are bugs that I found - uuids and concept name ids that were re-used and not unique
Closing this PR for now as I'm rethinking this approach and working on other issues. |
The goal of this PR is to address the issues raised in https://issues.openmrs.org/browse/O3-2448 and https://issues.openmrs.org/browse/O3-2465. This PR does the following:
See specific comments throughout the PR.
I have this as a Draft PR initially to show where I've been heading and looking for feedback / suggestions. This will obviously be disruptive and some work to get it working as expected in existing implementations that rely on current behavior. It will also need to be paired with changes to the O3 frontend to remove the calls to generate visit numbers, etc.
@corneliouzbett / @CynthiaKamau / @ibacher interested in thoughts / feedback. @mogoodrich FYI